1. Field of the Invention
This invention pertains generally to software applications designed for client-server use. More particularly this invention is directed to an improved system and method for providing automated remote object application support in a client-server object oriented environment.
2. The Prior Art
The client/server model is an approach to providing user-requested services or information. In the traditional client/server environment the client and the server are on the same machine or different physical machines connected by a network. The client asks for and receives services from the server. The client and the server are independent software applications; a client/server system would include those applications plus the operating systems on which each run, networking, and any related applications (such as a database).
The typical client/server model is based on computing as seen from the end user""s viewpoint, not that of the system or the application. Thus, the client is the application a user interacts with directly, whereas the server application, responding to requests from the client, is typically invisible to the user. Data presentation is for the benefit of the user, so the client application typically does most of the data-presentation-related computing in addition to some data manipulation. The server application typically does all the work associated with data collection and retrieval; large databases, for example, reside on servers.
The definition of client/server highlights the fundamental tasks each component in the client/server architecture must perform. Understanding required functionality gives insight into the software complexity of the client/server components.
Looking at the client component again, the client acts as the user entry point into the client/server environment. The client must have a user interface component, either GUI or CLUI. The user interface component must include the ability to parse input commands, represent data in whatever form the interface makes available to a user, keep any needed context for the duration of this session, and keep and use context-sensitive history data of interface usage. Thus, the client application must include full UI support.
In addition, client applications carry out some data manipulation locally. The minimal amount of local data manipulation may be restricted to managing a cache so that recently retrieved information can be reused or recalled without needing to go to the server again. Local data manipulation increases in complexity from there, and often includes generating reports or user-interface representations of data retrieved from one or more servers. If the data is scientific or business modeling data, local data manipulation can be extremely intensive requiring powerful workstations.
Finally, client applications must be able to interact with at least one server. Interacting with any server, whether the server is local or accessible via a network, minimally means the client application program must be able to understand and use the communications protocol being used between the two. Often this is implemented at the session layer of the OSI layered network model, but any particular implementation in a client may require interacting at a lower layer depending on the specific application. If a single client is interacting with more than one server, it is entirely possible the client application will need to access different servers using different protocols, meaning the client application must have been programmed with the protocol knowledge built-in.
In general, the client application manages all of the user interactions which effectively hides the server and the network from the user. This creates the illusion that the entire application is executing without the use of servers or networks. The client application must make this interconnectivity and dependency work seamlessly at the user level.
Briefly, the server is a reactive process which is activated by requests from clients. A server is designed to service requests from any number of clients, so must keep client request context. The server provides requested information, computations, or services other requests from clients. A server does not interact with other servers as a server. If it is determined that a server itself needs information from another server, and this service is to be performed by other than the client, the server then takes on the role of a client and requests information from another server. At that point, the server is now a client. Since the xe2x80x9cuserxe2x80x9d is a machine, the client application will not need to the human user interface portions of a typical client application. It will need all the other components, however. In a traditional setting, a server typically needs a more powerful hardware base than a client, and usually has far more support for secondary storage, multiple network connections, etc.
A very well known example of a client/server implementation is an internet client, or browser, such as Microsoft""s Explorer or Netscape""s Navigator, interacting over the internet with sites. A server is handling the interactions with the user at any site a user accesses with a browser (client).
In addition to the traditional kinds of data and services available from servers, the advent of object oriented programming has introduced new ones. As is well known in the art, object oriented programming entails defining a set or class of objects, including the objects"" content and the operations that may be performed on the object, called functions or methods. In a local application, the objects created and instanced are made visible to, and can be used by, the program itself and other local programs. Objects may also be accessed remotely, that is, objects created and instanced on one machine may be accessing by a program on another machine. Objects accessible on one machine by programs running on another machine became an additional set of services available via client/server applications.
To access remote objects, clients need to make use of the remote object""s functions and/or methods. To do this, the client program must have complete and detailed knowledge of both how to access the remote system over a network using some programming methodology, plus the details of how to use each remote object""s specific functions and methods, including details on how to pass required arguments to them in the chosen programming paradigm. This creates a significant additional burden to the users of the server; they must learn the minutia of the programming methodology that allows access to server and be able to write client applications. In addition to what must be done for client programs in general, accessing remote objects adds the requirement that a detailed understanding of each remote object""s interfaces be known. Note that this detailed knowledge must be known by the client programmer for each and every remote object type the client program may ever accessxe2x80x94in a large networked environment this can be an overwhelming task. In addition, if even one remote object changes its interface in any way, even a xe2x80x9csmallxe2x80x9d change, the client application would have to be reprogrammed to match, recompiled and re-installed.
Thus, although it is very desirable for client programs to access remote objects, the overall job is daunting. In addition to requiring the time of a skilled programmer to write the client application initially, there is a continuing maintenance problem with coordinating and tracking changes between every remote object type and every client application that accesses them. With multiple client applications wanting access to multiple remote object types, coordinating changes becomes logistically difficult.
Accordingly, there is need to simply the complexity associated with both the initial implementation of applications who access remote objects, and the maintenance of those applications when changes occur to the remote object""s methods and/or functions. The present invention satisfies these needs, as well as others, and generally overcomes the deficiencies found in the background art.
It is therefore a goal of the present invention is to provide a method and system for decreasing the complexity of implementing and using remote objects. It is also a goal to decrease the maintenance activities associated with accessing remote object functions and methods. It is a further goal of this invention to make the remote object""s functions and methods readily available to a user.
The present invention is a Distributed Command SHell (DCSH) which has several unique properties. The DCSH provides a system and method for allowing users to dynamically (in real-time, from a user""s perspective) identify a name and a remote object to which the user wants access. The DCSH, if the object is known, will create an instance of the special class of objects known as a holder-object. The DCSH then creates an entry in a name/holder-object table for this name and just-created holder-object pair. The name/holder-object table has two columns per entry. The first column contains the name the user will use to reference the public object, the second column contains a pointer to the holder-object instance just created. The holder-object, using information in a set of root objects (created when the DCSH is first started), contains all the information needed to access the public (usually remote) object just specified. As soon as this action is completed, the user may use the name at the start of a command line at the DCSH""s CLUI, and the DCSH will access the correct remote object.
Parameters to the command line having the remote object""s name are used to reference the remote object""s methods and/or functions. Parameters are also used for arguments to the methods/functions, if any. This allows a user to make full use of remote object methods/functions without having to know any details of the actual programming interface.
Coupled with the fact that the syntax at the DCSH CLUI is consistent, a powerful tool is created allowing non-programming users access to remote objects"" methods/functions, yet still available via scripts and at a CLUI. Thus, an expert, senior programmer can implement the DCSH and then all the other users of the DCSH embodied in the present disclosure can use server object functionality without having to learn a programming language and the details of the programming interface of each object being accessed.